Following the advice in this post brought back my Products folder in both Xcode 14 + 15. https://developer.apple.com/forums/thread/77406?answerId=778590022#778590022

@Tadd 's post above should be marked as the accepted answer.

I solved the issue by ensuring that only the aggregate target was compiled using the -configuration option – though there is still a problem with how Xcode behaves if one does not include this parameter. I changed my build command from this: xcodebuild -configuration Release -project AggregateProject.xcodeproj to this: xcodebuild -configuration Release -scheme "Build All Projects" -project AggregateProject.xcodeproj After compiling this way, all of the Products ended up in the default Derived Data location ( ~/Library/Developer/Xcode/DerivedData/AggregateProject-blahblah/Build/Products/Release) as expected, and no "build" folders were created next to the subproject's .xcodeproj files. Still, I don't understand why the build location settings of the subprojects, and Xcode's global setting, are not respected when you compile without the -configuration option. Maybe somebody has an idea. Best Wishes, Mark

For anyone looking here who might benefit, it seems that you can use NSNumbers for custom CMIO properties under macOS 14.x, but that doing so will fail under macOS 12.x I detailed the issue in this post. -- Mr. Fantastic

If you are having trouble getting your Camera Extension app to notarize with a Developer ID certificate, then follow the instructions in this excellent post from Quinn "The Eskimo". Doing what the Eskimo said got me my app up and running. You can skip "Entitlement Matters" and "Xcode Issues" since these deal with building a Network extension. Instead, focus on the sections starting at "Re-sign the App" The key is to make Developer ID profiles not only for your app, but for the camera extension as well, and to copy these into your app and camera extension as discussed below "replace the embedded provisioning profiles with their Developer ID profiles variants." I hope that helps someone save the three days of head scratching and research I lost on this topic. Good Luck!

For those that found this article because you searched (like me) for CMIO Error 8, and if you are attempting to notarize your app with a Developer ID certificate, then follow the instructions in this excellent post from Quinn "The Eskimo". Doing so allowed me to resolve my issue and get my Camera Extension app working. You can skip "Entitlement Matters" and "Xcode Issues" since these deal with building a Network extension. Instead, focus on the sections starting at "Re-sign the App" The key is to make Developer ID profiles not only for your app, but for the camera extension as well, and to copy these into your app and camera extension as discussed below "replace the embedded provisioning profiles with their Developer ID profiles variants." I hope that helps someone save the three days of head scratching and research I lost on this topic.

Like @superg and @KinWaver, my app has the same problem: it cannot see newly installed camera extensions without restarting the app. I have resorted to using an NSTask and a command line utility that I can execute periodically to send custom parameters to my camera extension. Because the NSTask gets the list of devices each time it executes, it can see the recently added devices and communicate with them. But this solution is slow, and give that other pass (QuickTime Player, Photo Booth, etc.) can receive dynamic updates regarding cameras, I don't understand why my app can't do the same. Any advice or other solutions would be greatly appreciated.

So I had the same failures yesterday (Feb 17), but as of 5:52am GMT on Feb 18th, 2023, I was able to use altool to notarize again successfully using altool. So maybe it was a temporary glitch. Tagging @Quinn and previous posters below so maybe they'll get a notification. @rowlands @mateofp @derekdkim @molnardavid84 @dpo1 @NickNikonenok @sbnoble @steven7 @tien6b0 @Johnny7531

So that any Apple representatives will see this is a widespread issue: Please take a look at this discussion among users of QLab, where someone has formulated a suggested text for their own petition: https://groups.google.com/g/qlab/c/QEm4OERFw_s Users of different software are having a similar discussion on Reddit: https://www.reddit.com/r/MacOS/comments/qhbt4n/how_to_disable_orange_dot/

I have mobilized the user community of my software Isadora here ( https://community.troikatronix.com/topic/7723/ ) by asking users to send their comments via the macOS Feedback page. I am also spreading the word to other related software communities. One of the users of QLab has already formulated a petition to send to Apple in this discussion in this discussion https://groups.google.com/g/qlab/c/QEm4OERFw_s -- their suggestion reads as follows: The Microphone in use indicator on displays that don't have the menu bar visible is undermining the viability of many pieces of software used for video display in the live events, conference and theatre industries. Whilst I have no objection to the orange dot appearing in a menu bar, professionals using Macintosh Computers for video playback must have complete control over what appears on output screens that are visible to audiences, which sometimes may include millions of people for a single event. The orange dot is as offensive and unacceptable to these users as it would have been if you had chosen to overlay a watermark on all display screens with an Apple Logo. Please provide the means of turning it off as a matter of urgency.

@eskimo First, to be clear: I am sure the old certificate is not compromised. I had to erase my entire system after MacOS Monterey corrupted my entire system. (See this post: https://developer.apple.com/forums/thread/694991) This is not my main development machine, and not the machine on which the code signing and notarization for my released software was done. Problem is, I can't remember the password I used when exporting the file -- it was simply done to be able to move the certificate to the Monterey partition. I'll keep guessing. But if I can't remember it, should I go ahead and create a new developer ID application certificate? Or should I export the certificate from my main development machine (a physical separate Intel machine) and import it on this M1 machine? I assume that doesn't work because the machine has totally different hardware. Please let me know if that's how I should handle this.

To Kai and All, I opened technical support incident on this bug. The word from Apple is that the new behavior described in my original report should be considered the correct behavior, and that -getRectsBeingDrawn:count: can no longer be relied upon. The expectation of developers who need drawing optimization that they "roll their own" system. The workaround offered by Kai does in fact work and Apple verified that it is a valid workaround, with the caveat that doing so will circumvent the operating system from optimizing the backing store used for your view. To implement the workaround, you need to add an override like this to your custom views: (void) viewWillDraw { if (gIsRunningOnBigSur) { CALayer* layer = self.layer; layer.contentsFormat = kCAContentsFormatRGBA8Uint; } } Note that I'm doing this only for Big Sur -- gIsRunningOnBigSur is set depending on the operating system elsewhere in my code I don't do iOS, but Kai indicates that you need a similar override on iOS for -layerWillDraw. I hope that saves somone else some hair pulling. Best Wishes, Mark

Kai_2 : Regarding this: "We found a fix for this issue which we derived about two years ago when the same problem turned up under iOS 12: set view.layer.contentsFormat = kCAContentsFormatRGBA8Uint." I tried this in my test application (https://github.com/TroikaTronix/BigSurDrawingTest) under Big Sur, and no difference regarding the update area reported by getRectsBeingDrawn:count: In my app, I simply set contentsFormat for every Custom view I created. Is there something else I need to do? Best Wishes, Mark

Thanks kai_2 for providing a second confirmation of this bug. Did you also submit your bug report using Feedback Assistant? Given that my code example (see GitHub link above) demonstrates this totally reproducible problem, it certainly would be good to receive some feedback from Apple that indicates this will be addressed. Right now in Feedback Assistant, it still says "Resolution Open" Best Wishes, Mark